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REMARKS 



In response to the Office Action, Applicant respectfully requests the Examiner to 
reconsider the above-captioned application in view of the foregoing amendments and the 
following comments. 

Discussion of Claim Rejections Under 35 U.S^C. $ 1 12, Second Paragraph 

In the Office Action, the Examiner rejected Claim 24 under 35 U.S.C. § 112, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. Applicant respectfully submits that Claim 24 
has been corrected by the above-amendments. 

Discussion of the Claim Rejections Under 35 U.S.C. 102(b) and lQ2(e) 

In the Office Action, the Examiner rejected Claims 1-29 under 35 U.S.C. § 102(e) as 

being anticipated by U.S. Patent No. 6,243,725 to Hempleman (hereinafter "Hempleman"). 

Claims 30-37 were rejected under 35 U.S.C. § 102(b) as being anticipated by U.S. Patent No. 

5,864,868 to Contois (hereinafter "Contois"). 

Applicant respectftilly submits that a claim is anticipated only if each and every element 

as set forth in the claim is found, either expressly or inherently described in a single prior art 

reference. See M.P.E.P. 2131. Applicant respectfully submits that the cited art fails to teach or 

suggest at least one limitation from each of the above-listed claims for the reasons discussed 

below. 



In one embodiment, a metadata editor is provided so that a user can edit during the 
execution of a program the types of metadata that is associated with a content file, e.g., an audio 
or video file. In response to these edits, the system is able to dynamically change the display 
structures that are associated with viewing such metadata. With respect to an embodiment of the 
invention in an electronic jukebox, a user can select a "category" property set. The category can 
correspond to a particular music genre, such as rock, classical, or jazz. In one embodiment, the 
category sets include a number of data fields that provide metadata for music items that are 
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associated with the genre. A user can configure the number, the type of, and the content of the 
data fields. Furthermore, the user can modify certain display sets that are associated with the 
category property set. The content of the display sets are displayed to a user upon a user request. 
For example, a user may want to add a data field with respect to a particular category of music. 
If the user enjoys rock music, the user can add a data field to store the name of the drummer for 
his rock audio files. The drummer's name is automatically displayed when the user requests to 
see the data relating to his songs that are associated with the "rock" category. 

In contrast, Hempleman describes a system for managing music, wherein the user can 
create playlists, edit the content of predefined data structures describing the music, and play the 
music. On col. 8, lines 25-37, Hempleman describes a data structure that is used to store certain 
information regarding the user's music. The data structure includes a number of tables, each of 
which contain a number of fields. For example, Hempleman includes a Track table that include 
a CD Number field, a Track field, an Artist Code field, a Type Code Field, a Track Title field, a 
Track Time Field, an File Name field, and a Beats Field. Furthermore, the data structure includes 
a Type field for storing the type of a particular music track. 

Hempleman does not teach or suggest that the types of fields that are stored and displayed 
may be different depending on the selected category or that they are user-configurable. For 
example, Hempleman does not teach that the types of metadata associated with "rock" audio files 
could be modified to be different than the types of metadata that is associated with "classical" 
audio files. Thus, Applicant respectfully submits that Hempleman fails to describe user- 
configurable "display sets" or "display groups" as is recited in independent Claims 1, 9, 11, 13, 
17, 19, 27, 30, 33 and 34. Furthermore, Hempleman does not teach or suggest providing in a 
program the ability for the user to add new types of metadata, as is recited in Claims 1,9, 1 1, 13, 
17, 19;24,27, 30, 33 and34. 

In the Office Action, the Examiner took the position that the feature of allowing the user 
to configure the types of metadata is shown on Figure 4C and 4G of Hempleman. See Office 
Action, page 8 with respect to the rejection of independent Claims 17 and 19. Applicant 
respectfully submits that Figure 4C merely describes a table listing certain audio tracks. 
Furthermore, Applicant respectfully submits that Figure 4G merely describes a graphical user 
interface for developing various playlists. Figures 4C and 4G and the corresponding description 
in the specification do not teach or suggest allowing a user to alter the type of metadata records 
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that are associated with the songs in the various displayed audio tracks. Since at least the above- 
limitations are not taught or suggested by Hempleman, Applicant respectfully submits that these 
claims are in condition for allowance. 



As discussed above, one embodiment of Applicant's invention allows a user to create 
new data types with certain display groups. In contrast, Contois describes a system by which a 
user can filter displayed files by selecting certain predefined filter criteria, e.g., category, 
composer, artist. See Figure 7. Applicant respectfully submits that Contois fails to teach or 
suggest allowing the user to define and create new types of data fields as may be desired by the 
user. 

Since Contois fails to teach. or suggest "providing a graphical user interface for allowing a 
user to create a type of data field to a display group that identifies metadata that is to be displayed 
with respect to a plurality of media files; providing a graphical user interface for allowing a user 
to provide data for the added data type; and displaying the display group having the added type 
of data field and the provided data for the added data type" as is recited in independent Claims 30 
and 34, Applicant respectfially submits that these claims are in condition for allowance. 



Since Claims 2-8, 10-12, 14-16, 18, 20-23, 25, 26, 28, 29, 31-33, and 35-37 each depend 
on of Claims 1,9, 13, 17, 24, 27, 30, and 34, Applicant respectfully submits that these claims are 
allowable for at least the reasons previously discussed and the subject matter of their own 
limitations. 



Applicant has endeavored to address all of the Examiner's concerns as expressed in the 
outstanding Office Action. Accordingly, amendments to the claims for patentability purposes, 
the reasons therefore, and arguments in support of the patentability of the pending claim set are 
presented above. Any claim amendments which are not specifically discussed in the above 
remarks are not made for patentability purposes, and the claims would satisfy the statutory 
requirements for patentability without the entry of such amendments. In addition, such 
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amendments do not narrow the scope of the claims. Rather, these amendments have only been 
made to increase claim readability, to improve grammar, and to reduce the time and effort 
required of those in the art to clearly understand the scope of the claim language. In light of the 
above amendments and remarks, reconsideration and withdrawal of the outstanding rejections is 
specifically requested. If the Examiner has any questions which may be answered by telephone, 
he is invited to call the undersigned directly. 



Respectfully submitted, 



KNOBBE, MARTENS, OLSON & BEAR, LLP 




Eric M. Nelson 
Registration No. 43,829 
Attorney of Record 
Customer No. 20,995 
(619) 235-8550 
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